In diesem Kapitel schauen wir uns die Aufgabenstellung an, die uns im Verlauf der Veranstaltung begleiten wird. Wir arbeiten an einem durchgängigen Praxisbeispiel, um die zentralen Techniken des Datenmanagements nicht nur theoretisch, sondern vor allem praktisch zu erlernen. Dazu gehören alle wichtigen Modellierungstechniken: Wir werden Entity-Relationship-Diagramme erstellen und verstehen, wie daraus ein semantisch klares Datenmodell abgeleitet wird. Zudem widmen wir uns der Normalisierung, erproben sämtliche Arten von SQL-Statements und binden schließlich die Datenbank an Java an. So verstehen Sie am Ende, wie eine moderne Anwendung in der Praxis Daten speichert und abfragt. Abschließend erstellen wir beispielhafte Ausdrücke der Relationenalgebra, einer formalen Sprache, die die mathematische Grundlage bietet, relationale Abfragen unabhängig von einer konkreten SQL-Implementierung zu formulieren und zu optimieren. Die Aufgabe besteht im Entwurf eines Rechnungsverwaltungssystems. Dabei wird jede Rechnung genau einem Kunden zugeordnet, während ein Kunde beliebig viele Rechnungen besitzen kann. Eine Rechnung selbst zeichnet sich durch vier zentrale Merkmale aus: Erstens durch eine eindeutige Rechnungsnummer, mit der wir sie zuverlässig referenzieren können. Zweitens durch das Ausstellungsdatum, das angibt, wann eine Leistung erbracht oder eine Ware geliefert wurde. Drittens durch einen Rechnungsstatus, der den Bearbeitungsstand abbildet, beispielsweise offen, bezahlt oder mahnfällig. Viertens durch die Zahlungsart, die nur erfasst wird, wenn die Rechnung bereits beglichen wurde, etwa Barzahlung, Überweisung oder Kartenzahlung. Mithilfe dieser Basisdaten können wir Abfragen nach offenen Forderungen durchführen, Zahlungsgewohnheiten analysieren oder automatisierte Mahnläufe implementieren. Der Rechnungsstatus wird als Aufzählungstyp (Enumeration) definiert und umfasst fünf Zustände: „offen“, wenn die Rechnung noch nicht bezahlt wurde; „bezahlt“, sobald die Zahlung verbucht ist; sowie „erste Mahnung“, „zweite Mahnung“ und „dritte Mahnung“, um den Mahnverlauf abzubilden. Diese Struktur ermöglicht es uns, den Überblick über ausstehende Forderungen zu behalten, Mahngebühren oder Zinsen gestaffelt zu berechnen und Kunden gezielt in klar definierten Eskalationsstufen anzusprechen. Auch die Zahlungsart wird als Enumeration abgebildet und umfasst die Werte bar, EC, Visa, Master und PayPal. Durch diese klar definierte Struktur ist jede bezahlte Rechnung eindeutig einer Zahlungsweise zugeordnet. Dies ermöglicht beispielsweise Analysen von Transaktionsgebühren oder automatisierte Abgleiche von Kreditkartenabrechnungen. Außerdem bildet diese Struktur die Basis, um später weitere Zahlungsoptionen wie Sofortüberweisung oder Kryptowährungen zu ergänzen. Kunden erhalten eine eindeutige Kundennummer zur eindeutigen Identifikation sowie eine vollständige postalische Anschrift, bestehend aus Straße, Hausnummer, Postleitzahl und Ort. Optional können Kunden Kreditkarteninformationen hinterlegen. Diese sensiblen Daten werden aus Sicherheitsgründen nicht direkt in der Kundentabelle gespeichert, sondern in einer separaten, geschützten Struktur abgelegt. Jede Kreditkarteninformation ist genau einem Kunden zugeordnet, sodass nachvollziehbar bleibt, welche Karte welchem Kunden gehört, ohne redundante Daten zu erzeugen. Die Entität „Kreditkarteninformation“ ist fest über die Kundennummer mit einem Kunden verknüpft (eins-zu-eins-Beziehung). Der Kartentyp wird als Enumeration erfasst, entweder „Visa“ oder „Mastercard“, wodurch andere Kartenarten ausgeschlossen sind. Weitere Attribute umfassen die vollständige Kreditkartennummer sowie den Monat und das Jahr, bis zu dem die Karte gültig ist. Dies gewährleistet, dass sicherheitsrelevante Informationen stets geschützt und eindeutig zugeordnet verwaltet werden. Kunden werden zudem über Spezialisierungen weiter differenziert: Ein Geschäftskunde ist eine Unterklasse des allgemeinen Kunden und besitzt zusätzlich einen Firmennamen sowie eine Steuer-Identifikationsnummer. Diese Informationen sind essenziell für rechtssichere Rechnungen und korrekte Abrechnungen mit Behörden. Ein VIP-Kunde ist wiederum eine spezialisierte Form des Geschäftskunden, der im System automatisch einen pauschalen Rabatt erhält, welcher auf jede Rechnung angewandt wird. Ein Privatkunde ist ebenfalls eine Spezialisierung des allgemeinen Kunden, jedoch mit anderen zusätzlichen Angaben: Anstelle eines Firmennamens werden hier Vor- und Nachname gespeichert. So wird sichergestellt, dass Firmen- und Privatkunden korrekt und eindeutig abgebildet sind. Eine Rechnung setzt sich stets aus mindestens einer Rechnungsposition zusammen, die zwingend genau einer Rechnung zugeordnet ist. In der Datenbank speichern wir in jeder Rechnungsposition die zugehörige Rechnungsnummer als Fremdschlüssel. Zusätzlich erhält jede Position eine laufende Nummer, beginnend bei eins für jede neue Rechnung, sodass die Reihenfolge exakt nachvollziehbar ist. Jede Rechnungsposition ist außerdem genau einem Produkt zugeordnet, das jedoch in beliebig vielen Rechnungspositionen auftauchen kann. Jede Position umfasst zwei zentrale Werte: die Menge des Produkts und den Einzelpreis in Euro. Daraus ergibt sich der Positionsbetrag, der wiederum für Summen- und Rabattberechnungen genutzt werden kann. Die Entität „Produkt“ enthält eine eindeutige Produktnummer als Primärschlüssel, einen Produktnamen, eine ausführliche Beschreibung sowie einen Standardpreis in Euro. Letzterer definiert den regulären Verkaufspreis und dient als Basis für Angebote und Rechnungspositionen. Zudem wird ein aktueller Lagerbestand gespeichert, um Nachbestellungen rechtzeitig auszulösen. Produkte und Lieferanten stehen in einer n-zu-m-Beziehung: Ein Produkt kann von mehreren Lieferanten bezogen werden, und jeder Lieferant bietet mehrere Produkte an. Diese Beziehung wird über eine Zwischentabelle realisiert, welche Einkaufspreise und Mengenkonditionen speichert. Die Entität „Lieferant“ ist durch eine eindeutige ID, einen Namen und eine Adresse gekennzeichnet. Über eine Zwischentabelle werden Mengenrabatte definiert, bei denen der Lieferant pro Produkt einen prozentualen Rabatt gewährt, sobald eine definierte Bestellmenge überschritten wird. Dies ermöglicht es dem System, automatisch den korrekten Einkaufspreis bei großen Bestellmengen zu berechnen. Die „Adresse“ wird als eigenständige Entität geführt, mit eigener ID, Straße, Hausnummer, Postleitzahl und Ort. Dadurch vermeiden wir doppelte Einträge und ermöglichen eine einheitliche Nutzung für Kunden und Lieferanten. Eine erste grafische Übersicht des Datenmodells zeigt konzeptionell die zentralen Entitäten und ihre Beziehungen: Rechnungen bestehen aus Rechnungspositionen, die wiederum Produkte referenzieren. Produkte stehen in einer n-zu-m-Beziehung mit Lieferanten. Kunden haben Rechnungen und optional Kreditkarteninformationen. Kundentypen werden spezialisierend unterschieden. Adressen sind zentralisiert nutzbar. Enumerationstypen für Rechnungsstatus und Zahlungsart gewährleisten Klarheit und Konsistenz. Zum Abschluss betrachten wir die Allgemeingültigkeit der Aufgabenstellung: Das hier modellierte Rechnungsverwaltungssystem lässt sich auch auf andere Anwendungen übertragen, beispielsweise Angebote, Bestellungen, Produktlager, Studierende mit Prüfungsleistungen oder sogar Musiksammlungen. Die grundlegenden Strukturen aus Entitäten, Beziehungen und Statusinformationen bleiben dabei stets ähnlich und bestätigen die breite Anwendbarkeit der Techniken aus diesem Praxisbeispiel.